Your job as an engineer will only be as good as your ability to communicate.
You may have the world's greatest engineering mind, but if you cannot express
your ideas to others, no one will benefit from, or know about your ideas.
Therefore, being able to express your ideas efficiently is a key to being a
successful engineer.
Writing reports and giving presentations are two of the most commonly employed means of expression in an industrial setting. A report or presentation should solidly convey your ideas to the audience in the shortest time possible. A report should clearly and concisely describe the progress (or completion) of your work to the reader. The report should be written in such a manner that an ordinary layman reading it will get an idea of your work's necessity, importance (why?), and its ultimate application (for what?), even if he or she didn't understand all the technical details that were explained in it.
The final project report should be written with the above goals in mind. Do not assume that the grader of the report is the only one reading it, and start off with a highly technical explanation, or assume he knows everything and just include the schematics, or source code without explanation. Instead, work your way up to the technical description in a clear and logical manner so that anyone reading the report will have some idea of what was achieved. Do not fill your report with tens of pages of schematics, VHDL code, and/or simulation waveforms, so that the report looks heavy with content. The final source and other run-time reports belong only in an appendix where an interested party can refer to them to get a complete understanding. Use the following guideline to write your report. The red headings generally apply to your final project, whereas the the blue ones apply to your design proposal.
Cover Page
The cover page should contain the title of the report, and a sub-heading indicating that it is the EE415 final project report/proposal for this quarter. Include the date, your name, and box number.
Table of Contents
This
is self-explanatory. Follow a standard format. Optionally, you can include a
list of figures and tables if you think the report needs one for clarity.
Introduction
This
is the part where a layman reading your report should get an overall idea of
your work. Use simple, non-technical language and introduce the reader to your
work (what is the purpose and history of the work? how was it achieved? was the
work successful?, etc.) Lastly, introduce the reader
to the rest of the report (what does the remainder of the report contain? what
does the appendix contain? etc.).
Description
This section should not necessarily have the sub-heading
"Description"; rather, use something like "The 16-bit
Microprocessor" instead. Use this section to introduce the reader to the
design you have implemented (what does it do? how is it implemented?)
Subsequent Sections
You
can have any number of these as you see fit. Partition the explanation to
logical parts and give each part a logical sub-heading. Some examples are the
architecture of the design and the modules (adder, subtractor, register, state
machine and/or controller design approaches). In each part, explain clearly how
you approached the design (did you use any examples from other designs?) and
any design challenges you overcame. Remember, keep your explanation clear. Use
plenty of diagrams; a block diagram is essential, and will give the reader an
overall idea of the design. If you used a structural description at a high
level, then include a block diagram or even a high-level schematic. Remember,
if your schematic has several hundred gates, the reader will not benefit from
it. In this case include circuit fragments to aid in the explanation. If your
design includes one or more state machines, include a state diagram or FSM (flow)
chart. Illustrate what each state does in the diagram (if it won't look too
cluttered). When explaining a section of the design, to help clarify, you can
include a VHDL code fragment for that part (for those using VHDL). Indicate all
references in the text, and use footnotes if appropriate. These recommendations
will greatly improve the readability of your report.
Schedule
Include
a proposed schedule for your project. You will have approximately five week to
work on the project. Describe how much time you intend to spend on logic
design, simulation, layout of final design, testing, etc. Later when you write
the final project report, you can explain if this schedule was realistic. For
example, did it take more time than you anticipated to do
the layout of the design?
Problems Encountered
You
don't need a separate section if you already addressed design problems in the
individual sections above. This section will contain challenges you faced
during the design process. Did the circuit simulate fine until you connected it
to the rest of the design? Did you have trouble with the initial simulation and
synthesized simulation not matching up? How did you overcome these obstacles?
The Final Design
Again,
think of a suitable headings. This section should
explain the design in its final form. Does the design do what it’s supposed to?
Is it fast and efficient? Can it be considered ready for production release?
Future Work
While
working on the design, did you think: "Gee, wouldn't it be neat if I can
add this feature so that it can also do this", or during the last week of
the quarter you realize that the method you've been using is not the best but
there is just not enough time to start over, then this is the place to address
these issues. If you couldn't meet the entire design specification, then
explain what else needs to be done to finish the design.
Conclusion
This
is the punch line section of the report, where you impress the reader about
what you have achieved. Be clear and concise, and go over the main points of
the report that were explained in detail in the preceding sections.
References
Include
all references used in your work. Use a standard format for references such as
MLA. The old ENG305J textbook may be of help here.
Appendix
Include
complete schematics, layout diagrams, VHDL source code, simulation results
(waveforms), and synthesis and implementation reports in a numbered appendix.
The simulation waveforms should be annotated, so that the reader clearly
understands what the simulation is showing. Include a heading for each waveform
and automatically generated report you include.
In
addition to the above format, pay attention to the following:
Remember,
the ultimate objective is to impress the reader. In an industrial setting, you
may end up getting a raise for your work. For this course, a good report will
get you a good grade. Even if you couldn't get most of the project done on
time, being able to clearly document what you managed to accomplish in a neat
report can sometimes turn things in your favor. This in no way implies that you
can get away with doing half the design and submit a good report. I will know
by reading the report how hard you have worked on the project.